The advantages of virtual machine technology have become widely recognized. Among these advantages is the ability to run multiple virtual machines on a single host platform. This makes better use of the capacity of the hardware, while still ensuring that each user enjoys the features of a “complete” computer. Depending on how it is implemented, virtualization can also provide greater security, since the virtualization can isolate potentially unstable or unsafe software so that it cannot adversely affect the hardware state or system files required for running the physical (as opposed to virtual) hardware.
FIG. 1 shows one possible arrangement of a computer system 700 that implements virtualization. As is well known in the field of computer science, a virtual machine (VM) is an abstraction—a “virtualization”—of an actual physical computer system. A virtual machine (VM) or “guest” 200 is installed on a “host platform,” or simply “host,” which will include system hardware, that is, a hardware platform 100, and one or more layers or co-resident components comprising system-level software, such as an operating system or similar kernel, or a virtual machine monitor or hypervisor (see below), or some combination of these. The system hardware typically includes one or more processors 110, memory 130, some form of mass storage 140, and various other devices 170.
Each VM 200 will typically have both virtual system hardware 201 and guest system software 202. The virtual system hardware typically includes at least one virtual CPU, virtual memory 230, at least one virtual disk 240, and one or more virtual devices 270. Note that a disk—virtual or physical—is also a “device,” but is usually considered separately because of the important role of the disk. All of the virtual hardware components of the VM may be implemented in software using known techniques to emulate the corresponding physical components. The guest system software includes a guest operating system (OS) 220 and drivers 224 as needed for the various virtual devices 270.
An objective of the VM 200 is to ensure that applications 260 running on the VM will function as they would if run on a “real” computer, even though the applications are running at least partially indirectly, that is via the guest OS 220 and virtual processor(s). Executable files will be accessed by the guest OS from the virtual disk 240 or virtual memory 230, which will be portions of the actual physical disk 140 or memory 130 allocated to that VM. Once an application is installed within the VM, the guest OS retrieves files from the virtual disk just as if the files had been pre-stored as the result of a conventional installation of the application.
Some interface is generally required between the guest software within a VM and the various hardware components and devices in the underlying hardware platform. This interface—which may be referred to generally as “virtualization software”—may include one or more software components and/or layers, possibly including one or more of the software components known in the field of virtual machine technology as “virtual machine monitors” (VMMs), “hypervisors,” or virtualization “kernels.” Because virtualization terminology has evolved over time and has not yet become fully standardized, these terms do not always provide clear distinctions between the software layers and components to which they refer.
In general, when implementing virtual machines, it is important to virtualize all useful functionalities of a physical machine. If functionality is not fully virtualized, then that feature becomes less useful in a virtual machine. Either that functionality cannot be used at all in a virtual machine, or it can only be used by one virtual machine at a time, if a “pass-through” mode to the physical resource is possible.
A problem exists, however, in the implementation of virtual machine resource reservations in certain clustering applications. For example, in certain clustering applications, SCSI-2 reservations are important for implementing application clustering functions. Such application clustering functionality is provided by products such as, for example, Microsoft Cluster Server® (MSCS) or Veritas Cluster Server® (VCS). To properly implement virtual machine resource reservations in an application clustering environment, SCSI-2 reservations should be fully virtualized. For example, the SCSI-2 RESERVE, RELEASE and RESET commands should be virtualized. As known by those skilled in the art, the SCSI-2 protocols were not originally developed with virtual machine technology support as an objective.
A common prior art setup is a two-machine cluster, where an application (e.g., Exchange® or Oracle®) runs on one machine (e.g., called the active node) and the other node (e.g., called the passive node) is available to take over if/when there is a failure. If the application fails on active node, the cluster software automatically starts up the application on the passive node. The data of the application is stored on a shared disk that is accessible by both machines. SCSI-2 reservations are used to protect the data on the shared disk, in case the application is accidentally started on more than one machine at once.
Utilizing a virtual machine architecture, where cluster software is executed on one or more virtual machines (e.g., virtual machine 200), would provide a number of advantages, particularly for scenarios that reduce the amount of hardware needed to get high availability. These scenarios often involve consolidating the passive nodes of many clusters into virtual machines that all run on the same physical machine. In this case, the shared storage may just be a single virtual disk with a single file system that contains the shared virtual disks for all the clusters. A problem exists, however, in the fact that prior art configurations cannot fully virtualize the SCSI-2 reservations that are expected to be existent by the cluster software. The cluster software expects to be able to lock out other applications from accessing a shared resource, in this case, a SCSI-2 compliant hard disk drive, disk drive array, or the like. The cluster software was written to function with a cluster of real machines, as opposed to one or more virtual machines. Consequently, in such a virtual machine architecture, SCSI-2 reservations on one shared virtual disk do not consistently and accurately prevent all access by other virtual machines to that disk, while not affecting access to the virtual disks of any other clusters.